Broadband access technologies such as cable, fiber optic, and wireless have made rapid progress in recent years. There has been a convergence of voice and data networks, which is due in part to the deregulation of the telecommunications industry in the United States. In order to stay competitive, companies offering broadband access technologies need to support voice, video, and other high-bandwidth applications over their local access networks. For networks that use a shared access medium to communicate between subscribers and the service provider (e.g., cable networks, wireless networks, etc.), providing reliable, high-quality voice/video communication over such networks is not an easy task.
One type of broadband access technology relates to cable modem networks. A cable modem network or “cable plant” employs cable modems, which are an improvement of conventional PC data modems and provide high speed connectivity. Cable modems are therefore instrumental in transforming the cable system into a full service provider of video, voice and data telecommunications services.
Service providers need to make different levels of service available to customers, typically with corresponding differences in price. For example, some customers may need relatively higher data transfer rates than others and are willing to pay a premium for a higher quality of service (“QoS”) that can provide such transfer rates. Other customers may be content with a slower and less expensive service. Typically, customers having a higher QoS and customers having a lower QoS use the same type of modem. Service providers can also assign different priority levels to customers having the same QoS. A service provider typically distinguishes between such customers based on configuration files assigned to different classes of customers.
However, service providers must apply other network controls in order to regulate various aspects of network traffic. In order to regulate bursty traffic, network administrators need to ensure that network resources are allocated in a fair and predictable manner, while still allowing customers to transmit bursts of data when appropriate. Two methods of regulating and shaping bursty traffic patterns are illustrated by the “leaky bucket” and “token bucket” models, which are illustrated in FIGS. 1 and 2.
Leaky bucket 150 of FIG. 1 has a capacity 155 for incoming data 160. These data 160 may be, for example, data that a subscriber would like to transmit. In this example, outgoing data 165 from leaky bucket 150 are transmitted at a fixed rate 170. The leaky bucket is useful in preventing data bursts, which is a benefit in terms of bandwidth allocation. However, the leaky bucket may not be satisfactory for subscribers because of its lack of flexibility and the potential for significant delays in data transfer.
FIG. 1A illustrates token bucket 180, which is a somewhat more sophisticated model for shaping data traffic. Tokens 185 may be considered authorizations for transmitting a predetermined unit of data; therefore, tokens are usually measured in bits or bytes. Tokens 185, which are represented as drops in FIG. 1A, flow into token bucket 180 at a fixed rate R, which is measured in data units per time unit (e.g., bits per second). Token bucket 180 has a capacity 190. In this example, token bucket 180 has a capacity of B data units. Capacity B is also referred to as the “burst size” of token bucket 180, because it is equal to the maximum data burst allowed by controller 192.
Data accumulate in buffer 195 until there are enough tokens in token bucket 180 to permit the data to be transmitted. For example, suppose the next data packet 196 awaiting transmission in buffer 195 has a size of b data units, where B>b. If token bucket 180 is full, data packet 196 may be sent immediately. If token bucket 180 is empty, data packet 196 will remain in buffer 195 until b tokens flow into token bucket 180. If token bucket 180 contains N tokens, where N<b, then data packet 196 will remain in buffer 195 until (b−N) tokens flow into token bucket 180.
Typically, if a subscriber were not transmitting data, token bucket 180 would reach its capacity 190 in a time on the order of one second or less. This fact is referenced in RFC 2697, which is hereby incorporated by reference. Section 3, ¶2 notes that “token counts Tc and Te are updated CIR [the Committed Information Rate, measured in bytes] times per second.” The token counts are not updated after the burst size has been reached. Because the burst size is less than the CIR, tokens would stop flowing into the token bucket in less than one second. After token bucket 180 reaches its capacity 190, excess tokens are discarded.
In this fashion, token bucket provides more flexibility than leaky bucket 150. Leaky bucket 150 does not permit data bursts, but instead smoothes bursty traffic. Token bucket 180 allows data bursts, but places limits on how bursty traffic can be. Accordingly, token bucket 180 generally provides more satisfaction to subscribers.
Another problem that must be addressed by service providers is the consumption of disproportionate amounts of network bandwidth. File-sharing applications such as KaZaA, Gnutella, etc., which provide software that causes a subscribers personal computer (“PC”) to perform some functions of a server, cause much more upstream traffic than was envisioned by the architects of Data Over Cable System Interface Specification (“DOCSIS”) and other protocols. This upstream traffic often causes subscribers to consume a great deal of bandwidth, even while remaining within their QoS parameters.
Network-based application recognition (NBAR), a feature of Cisco Systems' proprietary IOS software, has been used to reduce traffic rates related to file sharing applications. NBAR is a classification engine that can recognize a wide variety of applications, including Web-based applications and client/server applications (such as file-sharing applications), by detecting patterns at Layer 4 and above. Once the application is recognized, the network can invoke specific actions relating to the recognized application. For example, NBAR can be used to trigger changes in priority, QoS, etc.
However, programmers of file sharing applications are aware of NBAR's capabilities and keep altering file-sharing software to avoid detection. For example, the most recent release of KaZaA includes a “port-hopping” feature that makes detection with NBAR difficult or impossible.
It would be very useful to have more reliable methods for detecting when file-sharing applications, or other applications which consume disproportionate amounts of network bandwidth, are being used. Moreover, it would be useful to prevent or reduce such bandwidth consumption.